Amendment # 62 
regarding 

Full System Acceptance Testing 

This Amendment is executed by and between ERG Transit Systems (USA) Inc, a 
California corporation and wholly owned subsidiary of Vix ERG Pty Ltd, an Australian 
corporation, (hereinafter referred to as the “Contractor") and each of the following 
seven public transportation agencies (hereinafter referred to individually as an 
“Agency" or collectively as the “Agencies 1 '): 

a. Central Puget Sound Regional Transit Authority ("Sound Transit") 

b. King County ("King County") 

c. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

d. Pierce County Public Transportation Benefit Area (“Pierce Transit”) 

e. Snohomish County Public Transportation Benefit Area ("Community 
Transit") 

f. City of Everett (“Everett”) 

g. State of Washington, acting through the Washington State Department of 
Transportation, Washington State Ferries Division ("WSF") 

Recitals 


A. Effective April 29, 2003, each of the Agencies and the Contractor entered into 
Contract #229944 (“Contract”) to implement a Regional Fare Coordination System 
(“RFC System”) to establish a common fare system utilizing smart card technology. 
The Contractor is responsible for the development, implementation, operation and 
maintenance of the RFC System as specified in the Contract. 

B. In May of 2009, the Contractor and the Agencies agreed to the Agreement 
for Issuance of a Conditional Notice of Apparent Completion for Complete System 
Commissioning Milestone and Amendment #43 ("Conditional NAC Agreement"). 
Among other things, said Agreement provided the terms under which the Agencies 
would issue a Conditional Notice of Apparent Completion (NAC) for the "Completion of 
Complete System Commissioning" Milestone and the conditions that would need to be 
satisfied for issuance of a Full NAC. 
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C. Under Section 3.1 of Amendment #43, the Parties agreed that the Acceptance 
Testing Settling-In period would not end, and the Full System Acceptance Testing 
period would not begin, until the effective date of a Full NAC for the Completion of 
Complete System Commissioning Milestone. 

D. Although not all conditions for issuance of a Full NAC had been satisfied, 
progress had been made and the Parties entered into an Agreement for 
Commencement of Full System Acceptance (FSA) Testing, dated August 12, 2009 
("FSA Testing Agreement"). 

E. Under the FSA Testing Agreement, the first sixty-day FSA testing period 
commenced August 12, 2009. The System has remained in revenue service 
operation since then, although the conditions for commencement of the second and 
third sixty-day testing periods, as specified in the Contract and Section 2.3 of the 
FSA Testing Agreement, have not been satisfied. 

F. The Parties enter into this Amendment #62 to revise certain provisions of the 
Contract and the FSA Testing Agreement related to the terms and conditions for Full 
System Acceptance testing. 


Agreement 

NOW, THEREFORE, in consideration of the mutual covenants contained herein, the 
sufficiency of which is hereby acknowledged, the Contractor and the Agencies agree 
to the above Recitals, which are incorporated by reference herein, and the following 
terms. 


1.0 Purpose 

Among other things, this Amendment #62 summarizes the requirements for 
commencing and completing a single Measurement Period for Full System 
Acceptance (FSA) testing. The provisions of (a) the Contract; (b) the Agreement for 
Issuance of a Conditional Notice of Apparent Completion for Complete System 
Commissioning Milestone and Amendment #43 (signed May 11, 2009); and (c) the 
Agreement for Commencement of Full System Acceptance Testing (signed August 
12, 2009) shall remain in full force and effect unless expressly modified by this 
Amendment #62. 


2.0 Definitions 

Unless otherwise stated herein, capitalized terms in this Agreement shall have the 
same definitions as provided in the Contract and in the Agreement for Issuance of a 
Conditional Notice of Apparent Completion for Complete System Commissioning 
Milestone and Amendment #43. 
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2.1 Chargeable Failure means a Failure of an Element or type of Element other than 
a Non-chargeable Failure. The Parties have agreed that the following is a non- 
exhaustive list of examples of Failures that shall be classified as Chargeable 
Failures: 

a. Failures caused by a low battery or a failed battery, except that a failed 
rechargeable battery will only be deemed a Chargeable Failure if it will not 
hold a charge when properly charged using the appropriate charging unit or 
device; 

b. OB-FTP Failures caused by the lack of a Zener diode; 

c. Failures that are within the reasonable control of the Contractor even if the 
Failure was "minor in nature" or "easy to fix"; 

d. Failures caused by a power or communications outage if the outage was 
within the control of the Contractor; 

e. A Failure where a single Reboot does not remedy the Failure, or if a 
Reboot was required for the same device in the previous 7 calendar days to 
restore full operation (exception: if multiple reboots are required for a software 
upgrade). 

2.2 DEVI means a development issue which may be raised by any of the Parties. 

2.3 Disputed Failure means a Failure where after review and discussion, the FRT 
(Failure Review Team) does not come to agreement on the classification of the 
Failure as Chargeable or Non-Chargeable. 

2.4 Element means the devices, systems and subsystems of the RFCS identified in 
the Table in Section 4.0 below, each of which Element or type of Element includes 
any and all of its hardware, software, components, accessories and peripherals. 

2.5 Failure means an incident of an Element not performing its functions in whole or 
in part. 

2.6 Hardware Failure means a Failure due to a manufacturing defect, omission of a 
component, or failure of a hardware component of that Element. 

2.7 Installation Failure means a Failure due to hardware that is not installed 
according to the agreed instructions or guidelines. 

2.8 Key Performance Indicators (KPI) means the Reliability, Availability and 
Accuracy standards specified in Section 4.0 (“Subject Systems and Equipment”) of 
this Agreement. 

2.9 KPI Measurement Period is the interval of time during which the Key 
Performance Indicators are measured. 
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a. Prior to Full System Acceptance, the KPI Measurement Period shall be the 
minimum eight-weeks as defined in Sections 3.1. 

b. After Full System Acceptance has been achieved, the KPI Measurement 
Periods shall be periods of 3 consecutive calendar months following Full 
System Acceptance and for the duration of the Contract. 

2.10 Non-chargeable Failure means a Failure that (i) is beyond the control of the 
Contractor or its subcontractors, suppliers or any other person or entity performing 
the Work of the Contract; or (ii) has been agreed to be Non-chargeable by the 
Agencies. The Parties have agreed that the following is a non-exhaustive list of 
examples of Failures that shall be classified as Non-chargeable Failures: 

a. Failure caused by Agency network, equipment or software provided by an 
Agency vendor other than the Contractor, or Agency personnel. 

b. Failure caused by physical damage beyond normal wear and tear if the 
damage: (a) was not caused by the Contractor’s failure to comply with the 
“ruggedizing” and other requirements of the Contract; and (b) was not caused 
by a deliberate or negligent act of a person employed by the Contractor, its 
Subcontractors of any tier and their respective officers, directors, employees, 
agents and representatives. 

c. A Failure where (i) a single Reboot remedies the failure, (ii) no other 
Reboot was required for the same device in the previous 7 calendar days; and 
(iii) neither a Hardware Failure nor Software Failure is reported against the 
Element for the exhibited behavior. 

2.11 KPI Reporting Period 

a. Before Full System Acceptance, the KPI Reporting Period closes each 
week at the end of Saturday. 

b. After Full System Acceptance has been achieved, the KPI Reporting 
Period closes on the last day of each calendar month following Full System 
Acceptance. 

2.12 Reboot means an action that is undertaken to re-establish full operation of a 
device that is exhibiting unintended behavior or is operating at a reduced level of 
functionality. Typically this involves turning the device off and on, and/or resetting the 
power. In this context, Reboot does not include normal daily or shift startup of a 
device, nor does it include periodic restarts of a server device as may be required 
from time to time for normal system administration purposes, provided that such 
restarts are described as part of the documented operating or maintenance 
procedures for the device. 

2.13 Reported Failure means a Failure that is detected by the Contractor through 
automated system monitoring or other means, or is reported by an Agency by phone, 
email or other means. 


4 



2.14 Software Failure means a Failure due to a software malfunction, software 
design defect, configuration issue, or other Failure that is not a Hardware Failure or 
an Installation Failure. 

3.0 KPI Measurement Period 

3.1 Commencement: Prior to Full System Acceptance, the initial KPI Measurement 
Period shall commence on May 2, 2010. 

3.2 A process for reporting Failures of RFCS cards will be added to CDRL 20 
subject to agreement by the Agencies. Failures of RFCS cards shall also be covered 
by the provisions of Section 5 including but not limited to the treatment of Disputed 
Failures. 

3.3 Not later than June 1, 2010, the Contractor shall submit to the Agencies revised 
CDRLs 20, 21 and 39 as necessary to reflect the terms of this Amendment #62. 
Revisions to CDRL 39 shall include but are not limited to an explanation of how 
every Reported Failure is assigned to one of the Elements. Any partial payment 
otherwise payable under Section 10 shall not be paid until said revised documents 
have been submitted and issued a NAC. 

3.4 An Element shall "pass" its KPI Measurement Period for purposes of achieving 
Full System Acceptance if: 

a. the Element has met the applicable KPI standard(s) in Section 4 for a 
period of eight (8) consecutive weeks, based on evidence gathered by the 
Contractor, in accordance with the NAC'd CDRLs 20, 21 and 39 (as revised in 
accordance with this Amendment #62 and NAC'd by the Agencies) and the 
Failure Reporting procedures specified in Section 5 of this Amendment as well 
as any other evidence gathered by the Agencies; and 

b. the Element has no Severity 1 or 2 DEVIs assigned to it at the point in time 
when it meets the KPI standard(s) for the eighth consecutive week. 

The Contractor shall provide written notice to the Agencies if it believes an Element 
has passed in accordance with this Section 3.4. At the Agencies' request, the 
Contractor shall provide all documentation related to the measurement of the 
Element's KPI standard(s) and shall meet with the Agencies to review the 
documentation and respond to questions. In the event the Agencies dispute the 
Contractor's assertion that an Element has passed in accordance with this Section 
3.4, the Parties will meet and attempt to resolve the dispute. If they are not able to 
reach a resolution, the dispute shall be submitted to the Dispute Review Board in 
accordance with Section 3.1-34 of the Contract. 
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3.5 The KPI Measurement Period for purposes of achieving the Full System 
Acceptance Milestone shall continue until such time as all Elements have passed as 
described in Section 3.4. It is understood and agreed, however, that successfully 
meeting this requirement does not relieve the Contractor of any other requirements 
for achieving the Milestone of Full System Acceptance including but not limited to the 
requirements listed in Section 11 (“Other Contract Requirements”). 

3.6 The KPI standard(s) of each Element shall continue to be monitored and 
reported whether or not it has "passed" or is under dispute. 

4.0. Subject Systems and Equipment 

The following Table summarizes the Elements and types of Elements that will be 
monitored and measured for Availability, Reliability and/or Accuracy, during and after 
the KPI Measurement Period. “Assumed Operating Hours Per Day” is 24 for all 
Elements. 


A. Element 

B. Availability 

C. Reliability 

MOHBF = Mean 
Operating Hours 
Between Failures 

MTBF * Mean 
Transactions Between 
Failures 

D. Accuracy 

VoLTx = Votume of Transactions 
Val_Tx = Value of Transactions 

OB FTP 


30,000 MOHBF 

99.99%-100.01% 

(Vol_Tx) 

SA FTP 


30,000 MOHBF 

99.99%-100.01% 

(Vol Tx) 

P FTP 


30,000 MOHBF 

99.99%-100.01% 

(Vol Tx) 

GAK 


30,000 MOHBF 1 

99.99%-100.01% 

(Vol_Tx) 

DDU 


30,000 MOHBF 


WDOLS(on-board) 


30,000 MOHBF 


RCU 


30,000 MOHBF 


TRU 


5,000 MOHBF 

99.99%-100.01% 

(VaLTx) 

TVM card reader 


“l0,000 MOHBF 2 

99.99%-100.01% 

(Val Tx) 

CST (including any 
modules and peripherals 


5,000 MOHBF 

99.99%-100.01% 

(Val Tx) 


1 Excludes failures of non-Contractor supplied turnstiles or other components. 

2 Excludes any failures of non-Contractor supplied TVM components. 
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A. Element 

B. Availability 

C. Reliability 

MOHBF - Mean 
Operating Hours 
Between Failures 

MTBF = Mean 
Transactions Between 
Failures 

D. Accuracy 

VoMTx - Volume of Transactions 
Val_Tx - Value of Transactions 

in a CST set-up at any 
location including but not 
limited to Mail Center) 




DAC 

99.73% 


99.99%-100.01% 

(Vol Tx) 

BOC and BOC Client 

99.73% 


99.99%-100.01% 

(Vol Tx) 

Clearinghouse 

99% 


Both 99.99%-100.01% 
(Val_Tx) and 100% for 
autoloads (no autoload 
validation Chargeable 
Failures) 

Network 

99% 



Smart Cards 


10,000 MTBF 


Cardholder and 

Business Account 
Websites (as further 
described in Section 7) 

99% 



Agency and Call Center 
Websites (as further 
described in section 7) 

99% 



Reports 

(as further described in 
Section 7 and 8 of 
Amendment #62) 

99.73% 


99% 

(no missing, duplicative 
or erroneous data in 
each Report) 

TRU server 

99.73% 



WDOLS (base wireless 
access point) 

99.73% 




5.0 Failure Reporting and DEVI Severity Classification 

5.1 Every Reported Failure shall be opened in the Contractor's failure and 
performance monitoring and tracking system, regardless of the means by which it 
was identified by the Agencies or the Contractor (for example, email, telephone call, 
Contractor's personnel or Contractor's monitoring systems). 

5.2 At a minimum, the tracking system shall record the following information about 
every Reported Failure: 


7 




a. the applicable Element listed in Section 4.0 above to which the Reported 
Failure is assigned; 

b. the dates and times when the Reported Failure (i) started and (ii) was 
entered in the tracking system; 

c. the date and time when the Reported Failure was resolved and, for 
Elements subject to Availability measurement, the number of Out of Service 
Hours as defined in Section 7.0 for each Reported Failure; 

d. whether a Reported Failure was reclassified by the Contractor to be Non- 
chargeable, all in accordance with Section 5.4 below; 

e. if a DEVI has been raised regarding a Reported Failure and, if so, the 
DEVI number, initial severity classification and details; and 

f. if applicable, that a Reported Failure was proposed by the Contractor to be 
counted as a single Software Failure, with concurrence of the FRT, all in 
accordance with Section 5.5 below. 

5.3 Any DEVI that is initially classified as a Severity 3 or Severity 4 issue shall be 
reclassified as a Severity 2 issue if it results in a device experiencing functional or 
operational problems such that the device requires a Reboot in order to restore full 
operation according to the following rules: 

a. Where there are more than 300 of a device type (e.g. OBFTP, DDU, 
WDOLS) in active service, the DEVI shall be reclassified as Severity 2 if it 
results in more than 3% of the devices in active service requiring a Reboot to 
restore full operation. 

b. Where there are between 100 and 300 of a device type (e.g. GAK, SAFTP, 
PFTP) in active service, the DEVI shall be reclassified as Severity 2 if it 
results in more than 5% of the devices in active service requiring a Reboot to 
restore full operation. 

c. Where there is less than 100 of a device type (e.g. CST, DAC) in active 
service, the DEVI shall be reclassified as Severity 2 if any instance (i.e. any 
individual unit) of a device requires two or more Reboots in a single service 
day to restore full operation. 

5.4 Every Reported Failure shall be classified and recorded as one Chargeable 
Failure. A Reported Failure that remains in "open" status shall remain Chargeable 
and shall be counted as Chargeable unless and until it is "completed" and 
reclassified to Non-chargeable in accordance with the following process. After 
analysis, the Contractor may reclassify a "completed" Reported Failure as a Non- 
chargeable Failure if there is evidence that it does not meet Chargeable Failure 
definition in Section 2.1. Such reclassification shall be recorded in the tracking 
system and discussed by the Failure Review Team (FRT). If the members of the 
FRT do not agree on whether a Failure is Chargeable or Non-chargeable, it shall be 
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designated as a "Disputed Failure." If the inclusion of any Disputed Failures as 
Chargeable would affect whether or not an Element meets the applicable KPI 
standards, the Parties will meet in accordance with Section 3.4 and, if they are not 
able to reach a resolution, the Disputed Failures shall be submitted to the Dispute 
Review Board in accordance with Section 3.1-34 of the Contract. 

5.5 Non-Chargeable Failures shall not be included in performance measurement 
calculations. Each Chargeable Failure, in both the open and completed status shall 
be counted separately as one Chargeable Failure, unless the following change in 
counting methodology is approved by the FRT: 

a. Multiple occurrences of a Software Failure may be counted as one 
Chargeable Failure if the Contractor can provide sufficient evidence to 
demonstrate that all occurrences of the Software Failure were as a result of 
the identical root cause. Software Failures that are similar in nature, but not 
resulting from the same root cause, shall not be grouped together under this 
provision, and shall be considered as distinct and separate Software Failure 
occurrences. 

5.6 Until Full System Acceptance is issued, the FRT shall meet at least weekly at a 
mutually agreeable day and time and, if meeting in person rather than by telephone, 
at a mutually agreeable location. Contractor shall provide the Agencies with a 
weekly written report at least one (1) full business day prior to the FRT meeting and 
shall provide, at a minimum, the following: 

a. the report shall provide the information listed in Section 5.2 above for each 
Reported Failure entered or marked "completed" in the tracking system during 
the previous week; and 

b. every Reported Failure which the Contractor has, during the previous 
week, either reclassified as Non-chargeable under Section 5.4 or counted in 
accordance with Section 5.5. 

After Full System Acceptance is issued, the FRT meetings shall be held, and the 
reports shall be provided, on a monthly basis. The FRT meeting will be scheduled 
some time in the week after the KPI Reporting Period but prior to submittal of the 
report. 

5.7 Contractor shall provide reports within ten (10) business days after the end of a 
KPI Reporting Period for each type of Element that is subject to Reliability, 

Availability and/or Accuracy criteria. The reports shall include, by Element Type: 

a. Reliability, Availability and Accuracy results for the current KPI 
Measurement Period based on the calculations specified in Sections 6, 7 and 
8; and 

b. Historical Reliability, Availability and Accuracy results and trend analysis. 
Prior to the issuance of Full System Acceptance, this historical reporting shall 
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include all results and analysis back to the start of the initial KPI Measurement 
Period as described in Section 3.0. After Full System Acceptance has been 
achieved, the report shall be for the current KPI Measurement Period.. 

5.8 Reports provided pursuant to Sections 5.6 and 5.7 shall contain sufficient detail 
for the Agencies to independently verify reported measurements or compare it with 
Agency records for audit purposes. 

5.9 In the event that a Reported Failure is reclassified per the provisions of Section 

5.4 above or counted per the provisions of Section 5.5, historical results and any 
trend analyses shall be adjusted accordingly in the calculations. 

6.0 Reliability Calculations and Definitions 

6.1 Mean Operating Hours Between Failure (MOHBF) equals: 

Measurement Period (days) x Assumed Operating Hours (per day) x Active 

_ Devices _ 

Chargeable Failures 


6.2 Mean Transactions Between Failure (MTBF) for the Smart Card Element equals: 

_ Total Smart Card Transactions _ 

Chargeable Failures 

Smart Card Transactions means the sum total of all RFCS smart card transactions 
regionally that have been recorded during the KPI Measurement Period. 

6.3 Active Devices means the total number of units of a device type in active 
operation at all Agencies. Units are not included as Active Devices if they: (a) are in 
repair and if they have been replaced by an Active Device; and (b) spare units stored 
in Agency inventory. 

6.4 Assumed Operating Hours means the number of hours per day, as specified in 
Section 4.0, that a type of device is assumed to be operational for calculation 
purposes. 

6.5 A separate MOHBF or MTBF calculation, as applicable, shall be performed for 
each type of Element subject to a Reliability measurement as listed above. 
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7.0 Availability Calculations and Definitions 

7.1 Availability for applicable Elements shall be computed and reported as follows: 

Availability = Effective Operating Hours - Out of Service Hours x 100% 

Effective Operating Hours 

7.2 Effective Operating Hours equals 24 hours multiplied by the number of days in 
the Measurement Period less the number of Total Scheduled Maintenance Hours. 

7.3 Maintenance Window means the period of time agreed to by the Agencies when 
scheduled maintenance of an Element is permitted. 

7.4 Total Scheduled Maintenance Hours means the total actual hours spent by 
Contractor on an Element during the Measurement Period for Agency-approved 
maintenance activities, whether performed in the Maintenance Window or outside it 
subject to prior Agency approval. 

7.5 Out of Service Hours means the actual hours during a Measurement Period that 
an Element is at a reduced level of operation or functionality due to a Chargeable 
Failure. Out of Service Hours shall be computed from the time a Reported Failure is 
identified by the system, reported by the Contractor, or reported by the Agencies 
(whichever is earliest), until the time operation of the Element is restored to full 
operation. In the event that such restoration occurs through a temporary repair or 
workaround, the Reported Failure shall continue to be tracked and reported until 
such time as a permanent repair is implemented, however such repair time will not 
be counted as Out of Service Hours provided that normal operation of the element 
has been maintained during the repair period through temporary repair or acceptable 
(to the Agencies) workaround. 

7.6 A separate Availability calculation shall be performed for each Element that is 
subject to an Availability measurement as listed in Section 4 above. The specific 
provisions of Sections 7.7, 7.8, and 7.9 shall apply to the Availability calculations for 
the Elements of Clearinghouse, Websites and Reports, respectively, and these 
specific provisions shall take precedence over the general provisions of this Section 
7 in the event of any conflict. 

7.7 For the Clearinghouse Element, the term "Out of Service Hours" includes but is 
not limited to the following: 

a. the time it takes to complete End-of-Day process beyond 6:00 a.m. of each 
day, and the time it takes to generate the End of Day (Month) reports beyond 
8:00 a.m.; 

b. the time it takes to complete End-of-Month process beyond 6:00 a.m. of 
the day it is run, and the time it takes to generate the End of Day (Month) 
reports beyond 8:00 a.m.; 
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c. the time beyond 4:00 a.m. that it takes to complete the morning distribution 
of Configuration Data to the Agencies' Back Office Computers; and 

d. the time beyond 4:00 p.m. that it takes to complete the afternoon 
distribution of Configuration Data to the Agencies' Back Office Computers. 

Provided, however, the Agencies' agreement to the above times for completion of 
distribution of Configuration Data is limited to application during the initial KPI 
Measurement Period for purposes of Full System Acceptance. For all other 
purposes, the Agencies reserve their rights, to require earlier morning and afternoon 
distributions. 

7.8 The calculation of Availability for the Website Elements shall also be subject to 
the following. 

(a) All RFCS Websites shall have a minimum availability of 99.73%, 24 hours a 
day, 7 days a week. For purposes of calculating availability for the RFCS 
Websites, the term "Out of Service Flours" includes but is not limited to the 
time during which: (a) a website server or intermediary (middleware) server is 
not fully operational; (b) a URL or page is inaccessible or unavailable due to a 
Chargeable Failure; and (c) server-side or page rendering errors occur as a 
result of a Chargeable Failure. 

(b) Scheduled maintenance shall be conducted per the following maintenance 
windows. For purposes of the availability calculation, “Scheduled Maintenance 
Flours” shall be defined as the period between the start and end of actual 
maintenance performed, not the maintenance window: 

i. All scheduled maintenance on the Cardholder Website and Business 
Account Website shall be conducted during a maintenance window of 
midnight to 2:00 AM (Pacific Time) on a regular day as agreed with the 
Agencies. Upon written request from the Contractor and subject to Agency 
agreement, this window may be changed on a case-by-case basis if 
required for more extensive maintenance. 

ii. All scheduled maintenance on Agency Website and the Call Center 
Website shall be conducted within a scheduled maintenance window of 
10:00 PM to 3:00 AM (Pacific Time) on a regular day as agreed with the 
Agencies. 

iii. If a maintenance activity is required outside of the applicable 
scheduled maintenance window, the implementation of that change or 
maintenance activity shall be coordinated with the Agencies. 

(c) In the event that a Website failure, fault or error is detected that affects 
operation of any website, whether related to hardware or software: 
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i. the Agencies shall be notified via email to designated recipients 
within fifteen (15) minutes of such failure, fault or error being 
detected and persisting. 

ii. Within one (1) hour of such failure, fault or error being detected, the 
Contractor shall provide the Agencies with: 

1. An estimated time to restore the Website(s) to operation; 

2. Repairs or workarounds required or believed to be required to 
restore operation; and 

3. Description and estimated time of repairs required to 
permanently resolve the failure, fault or error if known. 

iii. The Contractor shall provide hourly status reports to the Agencies 
until the website is again fully operational. 

These notice and response time requirements control and take 
precedence in the event of any conflict with other notice and response time 
requirements in the Contract. Failures, faults and errors that persist less 
than fifteen (15) minutes do not require notification to the Agencies but 
shall be included in the Availability measurement for the affected 
website(s). 

(d) The Contractor shall implement and maintain an automated system to monitor 
and report on availability of all RFCS Websites. Said monitoring service shall 
attempt at five (5) minute or less intervals, to render various pages in said 
websites and shall track all instances when the selected pages did not 
respond or accurately display their content ("render") within five (5) seconds of 
the monitoring service's attempt. Pages to be monitored shall include at a 
minimum: 

i. Home pages for each RFCS website; and 

ii. login pages for each RFCS website, including execution of a login 
script. 

At Agency request, the Contractor shall provide the Agencies with the data from its 
monitoring and reporting systems. 

7.9 The calculation of Availability for the Reports Element shall also be subject to 
the following. 

a. All RFCS Reports shall have a minimum availability of 99.73%, 24 hours a day, 7 
days a week. The Reports Element shall be considered unavailable for purposes of 
calculating Out of Service Hours if any of the following occurs: 
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1. the user interface used to schedule or view a report is not operative, 
excluding corporate browser or network settings outside of the Contractor’s 
control; 

2. an attempt by an Agency or Business Account user to schedule or view a 
report produces a failure message that is not caused by an error of the 
Agency or Business Account user, except if the error message is produced 
because the report parameters produces a report generation that is estimated 
to execute for longer than six (6) hours; 

3. an ERG scheduled auto-generating report cannot be viewed in its entirety 
by an Agency user by the "availability" time listed for each type of report in the 
list of Auto-Generating Report Configuration v.1.0, attached hereto and made 
a part hereof as Attachment A; 

4. a User Generated Standard Report cannot be viewed in its entirety within 
the "Maximum Run Time" or other standard specified for each type of report in 
the list of User-Generated Report Areas attached hereto and made a part 
hereof as Attachment B; 

b. The Out of Service Hours will end when the complete report can be viewed by the 
Agency or Business Account user. 

c. Scheduled maintenance for the Report server shall be conducted per the 
following maintenance windows. For purposes of the availability calculation, 
“scheduled maintenance” shall be defined as the period between the start and end of 
actual maintenance performed, not the maintenance window: 

i. All scheduled maintenance on the Reports server shall be conducted 
during a maintenance window of midnight to 2:00 AM (Pacific Time) on a 
regular day as agreed with the Agencies. 

ii. If a maintenance activity is required on the Report server outside of the 
applicable scheduled maintenance window, the implementation of that 
change or maintenance activity shall be coordinated with, and subject to 
agreement by, the Agencies. 
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8.0 Accuracy Calculations and Definitions 

8.1 Accuracy for applicable Elements shall be computed and reported as follows, 
depending on whether accuracy for the Element is measured by volume or value of 
transactions as indicated in the Table of Elements in Section 4.0. The Accuracy 
calculation is based on comparing two independent representations of transaction or 
value data namely: a) transaction quantities or values collected by the element 
(“TransactionsA/alue Recorded by Element”) and b) corresponding data processed 
and recorded at the Clearinghouse (“Transactions StoredA/alue Reported at 
Clearinghouse”) according to the following formulas: 

Accuracyvoiume = Z Transactions Stored at Clearinghouse 

I Transactions Recorded by Element 

Accuracyvaiue = I Value Reported at Clearinghouse 

I Value Recorded by Element 

The comparison will in general consist of the following: 

Fare Processing Devices: Comparison of device’s raw data with audit 
register data as generated by the device and stored at CCH. 

DAC: Comparison of raw data stored at the DAC against 
corresponding data stored at the CCH. 

BOC: Comparison of summarized data stored at the BOC against 
corresponding data stored at the CCH 

CCH: Comparison of pre-processed data received at the CCH against 
post-processed data output and reported by the CCH. 

8.2 In the case of the Clearinghouse Element, passing the Accuracy KPI requires 
that the above calculation produces Accuracy measures between 99.99% and 
100.01% and that there are no Chargeable Failures related to the Clearinghouse 
autoload validation process. 

The Clearinghouse autoload validation process will verify that all autoload 
transactions received at the Clearinghouse at the start of payment request 
processing (at approximately 11pm daily) are entered into the batch and sent to the 
payment gateway. For every batch flagged by the Clearinghouse autoload validation 
process, a Reported Failure will be opened. The Reported Failure shall be 
considered a Chargeable Failure unless it is determined to be a result of a valid 
system constraint or business rule. 

8.3 In the case of the Reports Element, passing the Accuracy KPI shall mean no 
erroneous data in any report, inasmuch as 99% Accuracy is required. 

8.4 A separate Accuracy calculation shall be performed for each Element type that 
is subject to accuracy measurement as listed above. 
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9.0 


Contract Amendments 


9.1 Contract Section 6.11-11.4.7 is amended to read as follows: 

11.4.7 Acceptance Test 

Acceptance testing shall be performed at a system level after (a) 
the issuance of an unconditional Notice of Apparent 
Completions for the Complete System Commissioning 
Milestone; (b) the requirements of section 6.11-11.4.7.1 for 
ending the Settling-In period have been satisfied; (c) Go Live 
has started with all components and subsystems completely 
functional, operational, on-line, and in service; and (d) the 
Contractor has met the requirements for commencement of the 
acceptance testing provided in section 3.1 of Amendment #62. 

(a) Acceptance testing shall be conducted by the Contractor 
in cooperation with Agency personnel and shall be 
subject to review and approval by the Agencies. 

(b) Reliability calculations for a particular equipment type will 
remain consistent throughout the acceptance testing 
period. 

(c) The Agencies reserve the right to make changes to the 
Acceptance Testing Plan to demonstrate conformance 
with the Contract requirements 

9.2 Contract Section 6.11-11.4.7.3 is amended to read as follows: 

11.4.7.3 Acceptance Test Requirements 

(a) The Full System Acceptance Testing Measurement Period 
shall begin and end as provided in Amendment #62 and shall be 
conducted over a minimum of eight (8) consecutive weeks under 
revenue service conditions. 

(b) Should the equipment fail to meet the performance 
requirements as specified herein, Contractor shall make 
whatever improvements to the equipment and/or 
systems which are needed to meet the requirements. 

(c) Contractor shall continue to improve RFCS equipment 
and systems until the Contract requirements are met. 

9.3 Contract Section 6.11-11.4.8.7 is deleted. 
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10.0 Partial Payments In Advance of Full System Acceptance Milestone 

10.1 Once fifteen of the twenty Elements pass as specified in Section 3.4, $350,000 
will be payable to the Contractor for each passing Element. The Contractor shall 
provide an invoice to the Contract Administrator listing the fifteen or more passing 
Elements for which payment is sought under this Section 10.1. Payment shall be 
due after an invoice is approved in accordance with Contract Section 3.1-76.1. 

10.2 Any partial payments made under this Section 10 shall be reduced from any 
amount due upon completion of the Full System Acceptance Milestone. 

11.0 Other Contract Requirements 

11.1 In addition to all Elements passing the KPI Measurement Period as required in 
Section 3.4 of this Agreement, the requirements to achieve Full System Acceptance 
include the successful resolution of DEVIs, through software releases or otherwise, 
as follows: 

a. All DEVIs addressed in MR 10 have been closed with agreement of the 
Agencies; and 

b. All DEVIs listed in Attachment C (list of DEVIs as of date of this 
Agreement) have been closed with agreement of the Agencies; and 

c. All DEVIs raised beyond Attachment C have been closed with agreement 
of the Agencies to the extent that there are no Severity 1 and 2 DEVIs and not 
more than sixty (60) Severity 3 and 4 DEVIs. 

The Contractor commits to schedule, with the agreement of the Agencies, releases 
of DEVI fixes, third party software patches, and other software changes for 
promotion to production at least every three months until and after Full System 
Acceptance is issued, for the duration of the Contract, unless otherwise agreed in 
writing by the Agencies. The content and schedule of these regular releases after 
MR-10 will be developed by the Configuration Advisory Board (CAB) with Agency 
agreement. Such scheduled releases shall be in addition to any other releases 
necessary to resolve issues in compliance with the Contract's Software Maintenance 
response times. 

11.2 It is understood and agreed that this Agreement does not address all of the 
requirements in the Contract and the Agencies reserve the right to consider all such 
requirements in determining whether to issue Full System Acceptance. By way of 
illustration and not limitation, the requirements that must be met by Contractor to 
achieve Full System Acceptance include but are not limited to the following: 

a. The terms and conditions for issuance of an unconditional NAC for 
Completion of Complete System Commissioning Milestone have been met 
and an unconditional NAC has been issued. 
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b. The Software Documentation required under the Contract has been 
verified to have been deposited in escrow. 

c. The Contractor has provided to the Agencies documentation that all 
deficiencies, exceptions and issues identified, as of the date of Full System 
Acceptance, in the audits/assessment made under SAS 70, PCI and the 
annual Moss/Adams Security audit have been resolved and closed with 
agreement of the Agencies. 

12.0 Other Terms and Conditions 

All other provisions of the Contract not referenced in this Amendment Sixty-Two shall 
remain in effect. 

IN WITNESS WHEREOF, authorized representative of the Agencies and the 
Contractor have signed their names in the spaces provided below. 

ERG Transit Systems (USA) Inc. The Agencies 




Date: 
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